Infrastructure as code

Cette après-midi, DeepSeek V4 Flash (via OpenCode) a fait une boulette dans mon projet homelab.sklein.xyz !

En voulant corriger le Helmfile de déploiement de Hindsight, il a lancé :

$ mise run destroy-cnpg-hindsight

sans réaliser que cette task Mise allait lancer la commande suivante :

helmfile -f helmfile/helmfile.yaml.gotmpl destroy

sans remarquer que mon fichier helmfile/helmfile.yaml.gotmpl contenait tous mes services et pas seulement cnpg-hindsight !

Ce qui est marrant, c'est qu'après le « Oups », il a tout de suite essayé de se rattraper. Heureusement, je suis au début de l'installation de mon homelab — rien d'important à perdre — et j'ai pu tester que la restauration du backup continu de CloudNativePG basé sur barman fonctionne bien.

DeepSeek V4 Flash n'est pas à blâmer : je ne l'ai pas aidé avec mes instructions, je lui ai tendu un piège.

Suite à cet incident sans gravité, j'ai pris conscience que faire travailler un agent de coding sur un projet d'Infrastructure as code est bien plus risqué que sur un projet de développement cloisonné, sans accès à la production.

J'ai commencé par ajouter ces quelques lignes dans mon fichier AGENTS.md :

## Safety Rules

- **Never run any `destroy-*` script or `helmfile destroy` command without explicit user confirmation** in the same conversation turn. Always ask first.
- If you must run `helmfile destroy`, always use `--selector name=<release>` to target only one release.
- When in doubt about a command's destructiveness, ask before executing.

Ensuite, j'ai remarqué que l'agent plan de OpenCode avait par défaut un accès trop large au tool bash pour un projet d'Infrastructure as code, je me suis lancé dans le renforcement des permissions :

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "plan": {
      "permission": {
        "bash": {
          "*": "ask",
          "kubectl get *": "allow",
          "kubectl describe *": "allow",
          "kubectl logs *": "allow",
          "kubectl top *": "allow",
          "tofu plan*": "allow",
          "tofu show*": "allow",
          "tofu output*": "allow",
          "tofu state*": "allow",
          "helm list*": "allow",
          "helm status*": "allow",
          "helm diff*": "allow",
          "helmfile *list*": "allow",
          "helmfile *status*": "allow",
          "helmfile *diff*": "allow",
          "git log*": "allow",
          "git diff*": "allow",
          "git status": "allow",
          "git show*": "allow",
          "jj log*": "allow",
          "jj diff*": "allow",
          "jj status": "allow",
          "ls*": "allow",
          "find*": "allow"
        }
      }
    }
  }
}

Ensuite, je me suis demandé s'il existait des solutions clé en main de limitation d'accès aux commandes cli, du même style que rtk, pour autoriser seulement des commandes de lecture sans risque.
#JaiDécouvert Prempti et agentsh. Je me suis demandé si l'intégration de l'un de ces outils n'allait pas entrer en conflit avec rtk. En étudiant les issues sur la sécurité de rtk, j'ai découvert que : rtk contourne le système de permissions d'OpenCode.

En cherchant un outil d'Infrastructure as code pour Grafana, #JaiDécouvert Grizzly.

Un projet qui a débuté en mars 2020, développé en Go par l'équipe de Grafana.

A utility for managing Jsonnet dashboards against the Grafana API

J'ai parcouru l'intégralité de la documentation et je suis ravi, ce projet correspond parfaitement à ce que je cherchais depuis des années !

Avant de découvrir cet outil, j'écrivais des scripts Python ou Bash d'exportation et d'importation de dashboards via l'API de Grafana.

Je souhaite l'utiliser dans le Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS. Dans le repository basic_ubuntu_server_install_playground.

Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

• sudo apt upgrade -y
• ou sudo apt dist-upgrade -y (plus risqué)
• ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

• Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
• Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

• J'arrête les services sur server(n+1).servers.example.com ;
• J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
• Je relance les services sur server(n+1).servers.example.com
• Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
• Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

• Une grande sécurité ;
• L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
• Une durée de coupure limitée et maîtrisée ;
• La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
• La garantie du bon fonctionnement des scripts de déploiement automatisé ;
• La vérification de l'efficacité des scripts de restauration des sauvegardes ;
• Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.